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y associates would tell you I have two very irri- 

tating habits; the first is my propensity for long, 

drawn-out jokes of the ‘shaggy dog’ sort, and the 
second my desire for stationery gimmicks like plastic 
paper clips, staplers that need no staples, and combina- 
tion pen/screwdrivers. 

Among my prized possessions is a five-inch high 
dodecahedron. This plastic paperweight has 12 identical 
faces, each a regular pentagon, and each with a month of 
the year printed on it, making it a great calendar. 

I've asked programmer friends what this reminds them 
of; only one recognised that the 12-sided shape is the 
basis of the old computer game known under a variety of 
names, including Hurkle or Hunt the Wumpus. 

This adventure game is easy to build and play, and 
exercises programming and analytical skills. You can use 
your ingenuity to tailor it to your style. The version we 
will discuss here will be called Dragon Hunt. 


Looking for Dragons 

In Dragon Hunt you're lost in a cavern composed of 12 
interconnected chambers. Each chamber has doors lead- 
ing into four others — those doors are lettered A, B, C and 
D. You're equipped with a lantern, a crossbow and three 
quarrels (an arrow for the crossbow) and placed in one 
of the chambers. In another there’s a slumbering dragon, 
who'll wake and eat you if you go into its chamber. 

The only way to deal with this dragon is to shoot it 
(once) through the door from an adjoining chamber. 
When you are in a chamber connected to the dragon’s, 
you'll hear it snoring. 

You can travel from chamber to chamber. But one 
chamber is shaped like a chute, and once you step into it 
you slide out of one of its doors, either in to an empty 
chamber, out of the door, or into the dragon’s lair. 
Another chamber has an underground torrent, and your 
armour will drag you to the bottom. 

Some adventurers try to map their way by dropping a 
quarrel or leaving their lantern. If you leave a quarrel, 
you risk running out of ammunition; if you leave your 
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lantern, you have a 50 percent chance of choosing the 
wrong door as you exit a darkened chamber. 

The object of the game is to hunt and kill the dragon. 
If you are eaten or drown, or fire all your arrows without 
hitting the dragon, you have lost the game. 


Designing the Game 

Let’s consider this game’s design and implementation in a 
computer language. Like many computer games, it is 
interactive, and except for keyboard and screen there is 
no input/output activity. This makes it ideal for the sim- 
plest languages; you may consider writing it in GW-Basic, 
or, with a few supporting utility programs, in the MS-DOS 
BAT language, or in one of its successors like 


Hyperkinetix’s Builder or Clockwork Software’s FromBAT. 


I think of programs like this as a set of beads strung 
together to make a whole. Each bead is a piece of code, 
data or technique. The beads in this program include a 
method of keeping track of which chamber the adven- 
turer is in, and which five chambers neighbour it. 
Another bead will keep account of where the quarrels 
and the lantern are, and others record where the dragon, 
chute and torrent are. 

There are many tiny routines that must be set up to 
communicate between the program and keyboard user. 
These include those that report things like seeing light 
through a particular door, hearing a snore, and detecting 
the sound of rushing water or whistling wind. The choice 
of going through a door, shooting through a door, pick- 
ing up or dropping an arrow or lantern must also be 
offered and acted upon. 

At the design stage, it’s wise to think in a generic way, 
using programming principles without confining yourself 
to a language. Let’s write down those beads we can think 
of at this stage. Firstly, how caves — numbered one to 20 
— are interconnected (probably best as a table). Secondly, 
location pointers for the adventurer, dragon, chute, tor- 
rent, lantern, and each quarrel. Each can be a number 
between one and 20, representing a chamber number. 

Thirdly, a random starting point for the adventurer, 
dragon, chute and torrent, each different. The lantern and 
three quarrels will be with the adventurer, until he drops 
each or fires a quarrel. Fourthly, reporting dangers in 
neighbouring chambers. Fifthly reporting the contents of 
current (safe) chamber; was a quarrel or lantern dropped 
here earlier? Sixthly, reporting light from the lantern if it’s 
in an adjacent chamber, specifying the door. Seventhly, 
what happens to the adventurer when he steps through a 
door; will it be a safe chamber, the dragon’s lair, the tor- 
rent or the chute? 

Eighthly, if the adventurer steps through a door into 
the chute, his destination should be chosen from the five 
doors of the chute’s chamber at random. Finally, if the 
adventurer chooses a door when he has no lantern in his 
possession — and he has not chosen the door with light 
coming through — he stands a 50 percent chance of fum- 
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bling in the dark and choosing the wrong door. 

The caves are interconnected in a complicated way, 
and that’s where the dodecahedron shape comes in. Each 
face of the dodecahedron is like one of our chambers, 
and borders on five other faces. If you were to take this 
shape, number the faces one to 12, and create a table for 
them, it might look like this: 


Bordering Chambers 


Chambers 


From this you will see that chamber seven borders on 
chambers two, six, eight, 11 and 12. In most languages 
(including Basic) this table would be best recorded in a 
DIM (dimension) statement, or its equivalent. Look in the 
index of your language manual for DIM and Arrays. 

As a programmer, when you use such a table you'll 
know which chambers are behind which doors, just by 
knowing the current chamber number. The routine that 
handles what happens when the adventurer enters a 
chamber should look at the neighbouring chambers, and 
then report whether the player can hear snoring, 
whistling or water, and whether he can see a light. 

Don’t specify which door leads to which sound, but 
say which door leads to the light. Don’t say the number 
of any cave, just identify each as ‘here’, and its bordering 
caves through the doors A, B, C, D and E. 

There are many refinements you can introduce into 
this program; the player might lose one quarrel if he falls 
into the chamber with the chute, he and his lantern may 
part company, falling into different chambers. 

When a player enters a chamber where he’s previ- 


ously dropped a quarrel, he should be told of it, unless 
there’s no lantern with which to see it. From any chamber 
you may hear any or all of the three dangers; report them 
in an arbitrary order, or you'll be providing extra clues. 

The end is complicated; the player can die because of 
the dragon or torrent, or run out of quarrels, so the pro- 
gram should test for this. Note that not having a quarrel is 
not the same as running out; he may have dropped one. 

You can add graphics to the program if you wish, or 
any other sort of complication. I'll be happy to receive 
source submissions in any sort of language. 


Hickory Dickory Dock 

Jim Bartholomew (Bo’ness, West Lothian) reminded me 
of the age-old problem encountered by Amstrad PC1512 
and PC1640 users. If the users of old Amstrad PC’s load 
MOUSE.COM as provided, it fiddles with interrupts, 
triples the system clock speed for its own purposes, and 
then passes only every third tick back to MS-DOS. 

That’s all very well, but not everyone is an Amstrad 
user; several programs, including GW-Basic and 
QuickBASIC, set the clock back to its proper speed. Yet 
MOUSE.COM will still be passing back only one tick in 
three to MS-DOS. This will make the system clock appear 
to run very slowly, and efficiency-measuring programs 
will indicate fantastic processor speeds. 

For Amstrad users with this problem, short patches to 
MOUSE.COM are available to correct it. 


Flavour of the Month 
In PC PLUS, issue 63, I commented on OOP (Object- 
Oriented Programming) as being nothing very new or 
even good, as it’s hard to adapt existing programs into 
this straightjacket. I expected abuse about my rashness. 
It’s early days yet, but the resulting post has been in 
agreement with me. I hoped to provoke programmers to 
create something marvellous to demonstrate how wrong I 
am. Will anyone defend OOP (or some other flavour of 
the month)? In coming months I will share with you some 
of the mail, but it’d be nice to get a dissenting vote! @ 


Tips, arguments and ideas are gratefully received by: 


Wilfs Programmers’ Workshop 
PC PLUS Magazine 

Beauford Court 

30 Monmouth Street 

BATH, BA1 2BW 


An easy suggestion for pacing a program, whatever the speed of 
the processor, has been sent to me by Jim Bartholomew (see 
Hickory Dickory Dock). His method is not an overall solution, but it 
can be useful. 

He has decided to take advantage of the fact that there is a 

timer interrupt, which takes place approximately every 55 millisec- 
_ onds, regardless of just how fast everything is actually going. 
| Whenever this interrupt occurs (18.2 times a second), the value in a 
| particular place in memory is incremented. This is at the address 
- 0000:046C (hexadecimal). 
| The 4 bytes at this location contain a binary count of timer 
|| interrupts. Binary long numbers (such as this 4 byte example) are 
| kept in the PC with their bytes in reverse order, so we only need to 
_ think about the first byte at that address constantly changing part 
of that 4 byte count. — 
For example, if you have a program that updates the display, 
se can be regulated to happen about 18 times a second, simply 
ailing this function timer-control just before updating. It will 
ly pass back control when a timer interrupt has occurred. This 


PC PLUS February 92 


PLAYING SAFE AT ANY SPEED | 


fragment is in C, but the principle can be programmed in other lan- 
guages quite readily. 


void timer_control (void) 
{ 


static int lasttick = 0; 
int far *ticker = MK_FP(0x0000,0x046C); 


while(lasttick == *ticker); 
lasttick = *ticker; 


} 


This is the equivalent to looking at the time and looping until the 
clock ticks. The time-waster in this code is the while command, 
which does nothing until the value in ticker is different from the 
value held in lasttick. 

There is one hitch; to make your timing accurate while you're 
doing some kind of animation you must to call the function at least 
as fast as the counter is being updated. 


BACKGROUND PROGRAMMING 


SPEEDING UP YOUR KEYS 


eee 
_SPEEDING UP YOUR KEYS | 


In PC PLUS, issue 63, we discussed responding to keys faster than 
the typematic rate allows. Jim Bartholomew (see Hickory Dickory 
Dock) offers this code, based on the fact MS-DOS gets two signals 
per key press, one when the key’s struck, one when it's released. 

The first signal is the scan code, which is the key’s fingerprint. 
High-level language users don’t normally care much about scan 
codes, but they are necessary for the working of the useful KEY 
instructions in GW-Basic. The second signal is the scan code with 
its top bit (hex 80) set on. The keyboard generates two hardware 
interrupts, which BIOS (Basic Input/Output System) sees and uses, 
but it only passes on the first of these values to MS-DOS users. 

Jim bypasses the MS-DOS interpretation of keystrokes in this 
example by intercepting the code that handles incoming interrupt 
09 signals. In this way this program can know when the operator 
has removed his finger from the keyboard. Jim then treats the cur- 
sor arrow keys in a special way; pressing one means ‘move in this 
direction as long as the key is held down’. 

A by-product of this method is that you can hold down two 
direction keys simultaneously, and move diagonally. This program 
is written in Turbo C, using this technique. It moves a solid blob 
around the screen, under control of the cursor arrow keys. [ESC] 
terminates the program. 


£include <stdio.h> 
f£include <conio.h> 
f£include <dos.h> 
fdefine OFF 0 
fdefine ON 1 
void initialise(void) ; 
void finish(void) ; 
void timer_control (void) ; 
void interrupt (*oldkeyscan) (); 
void interrupt keyscan(void); 
void cursor(int status); 
int uparrow=OFF, dnarrow=OFF, 
ltarrow=OFF, rtarrow=OFF, escpress=OFF; 
void main(void) 
{ 
unsigned char blank=32, blob=219; 
int x=40, oldx=40, y=13,oldy=13; 
/* screen coordinates, initialised to centre */ 
initialise(); 
gotoxy (x,y); 
/* display the blob */ 
putchar (blob) ; 
/* keep going until escape pressed */ 
while(!escpress) { 
/* prevent buffer overflow */ 
while(kbhit()) getch(); 
/* pace the speed of movement */ 
timer_control (); 
/* modify coordinates according to key(s) pressed */ 
if(ltarrow) x-- ; 
if(rtarrow) x++; 
if(uparrow) y-- ; 
if(dnarrow) y++; 
/* use modulo arithmetic to ensure 
coordinates stay on screen */ 
x = (x+79)%80 + 1; 
y = (y+24)%25 + 1; 
/* when blob is moved, blank old image 
as well as display new image */ 
if(oldx != x || oldy != y) { 
gotoxy(oldx, oldy); 
putchar (blank) ; 
oldx = x; oldy = y; 
gotoxy (x,y); 
putchar (blob) ; 


} 
} 
finish(); 

} 

void initialise(void) 

{ 
clrscr(); 
cursor (OFF) ; 

/* save original INT 09 vector */ 
oldkeyscan = getvect (0x9); 

/* replace with our own vector */ 
setvect (0x9, keyscan) ; 

} 

void finish(void) 

{ 

/* restore original INT 09 vector */ 
setvect (0x9, oldkeyscan) ; 
cursor (ON) ; 

} 

void timer_control (void) 

{ 
static int lasttick = 0; 
int far *ticker = MK_FP(0x0000,0x046C); 
while(lasttick == *ticker); 
lasttick = *ticker; 

} 

void interrupt keyscan(void) 

{ 
unsigned char scancode; 

/* read scancode (just what INT 09 normally does) */ 
scancode = inportb(0x60); 

/* let INT 09 do its own job - but come back here */ 
(*oldkeyscan) (); 

/* work out what happened, and record results */ 
switch(scancode) { 
case 0x01 : escpress = ON; break; 
/* detect the PRESSING of arrow keys */ 
case 0x48 : uparrow = ON; break; 
case 0x50 : dnarrow = ON; break; 
case 0x4B : ltarrow = ON; break; 
case 0x4D : rtarrow = ON; break; 
/* detect the RELEASE of arrow keys */ 
case 0xC8 : uparrow = OFF; break; 
case 0xD0 : dnarrow = OFF; break; 
case 0xCB : ltarrow = OFF; break; 
case 0xCD : rtarrow = OFF; break; 
} 

} 

void cursor(int status) 

{ 
union REGS regs; 

/* BIOS interrupt 0x10, function 01 */ 
regs.h.ah = 1; 
switch (status) { 

/* make cursor invisible */ 
case OFF ; regs.h.ch = 0x0C; 
regs.h.cl = 0x00; 
break; 

/* make cursor visible */ 
case ON : regs.h.ch = 0x06; 
regs.h.cl = 0x07; 
} 

/* BIOS interrupt 0x10 
int86 (0x10, &regs, &regs) ; 

} 


Try incorporating this into your programs; thanks very much, Jim. 
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